Method and system for implementing and managing an enterprise identity management for distributed security

ABSTRACT

An Enterprise Identity Management system includes a registration component, an ownership component, and an audit component. The registration component is configured to associate a user ID with specific accounts that are accessible via a computer system. The ownership component is configured to verify the ownership of the accounts. The audit component is configured to perform periodic checks to ensure the validity of the association between the user ID and the ownership of the accounts.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority to, U.S. Ser.No. 12/816,296 filed on Jun. 15, 2010 and entitled “METHOD AND SYSTEMFOR IMPLEMENTING AND MANAGING AN ENTERPRISE IDENTITY MANAGEMENT FORDISTRIBUTED SECURITY.” The '296 application is a continuation of, andclaims priority to, U.S. Pat. No. 7,765,232 issued on Jul. 27, 2010 andentitled “METHOD AND SYSTEM FOR IMPLEMENTING AND MANAGING AN ENTERPRISEIDENTITY MANAGEMENT FOR DISTRIBUTED SECURITY” (aka U.S. Ser. No.11/457,076 filed on Jul. 12, 2006). The '076 application is acontinuation of, and claims priority to, U.S. Pat. No. 7,143,095 issuedon Nov. 28, 2006 and entitled “METHOD AND SYSTEM FOR IMPLEMENTING ANDMANAGING AN ENTERPRISE IDENTITY MANAGEMENT FOR DISTRIBUTED SECURITY”(aka U.S. Ser. No. 10/334,271 filed on Dec. 31, 2002). The entirecontents of both are hereby incorporated by reference.

FIELD OF INVENTION

This application generally relates to computer systems and moreparticularly to a method and system for managing user identities in acomputer system.

BACKGROUND OF THE INVENTION

Computer systems have evolved to the point where it is possible for auser to remotely access personal information via a computer. Forexample, one can check account balances, purchase securities, purchasegoods and check the status of goods, and the like, through the use of apersonal computer by using, for example, an Internet browser.

In providing services such as those listed above, it is desirable thatcertain types of information be accessible only by authorized users. Forexample, only the account holder should be able to access informationregarding a bank account, be able to perform certain activities (e.g.,transfers and withdrawals) on said bank account, or be able to purchasegoods.

In the past, such security has typically been provided in the form ofthe combination of a user id and a password. For example, an account ata bank may be protected by having a user “log in” to the bankingapplication by providing a user id and password. However, such asecurity system may not be as secure as desired. For example, if anunauthorized user were to become aware of the user id and password, theunauthorized user would then be able to access information and performtasks that should be limited to a select group of people.

There are several problems with the above-described scenario. Theassociation between a user ID and an account may become broken,resulting in a loss of on-line services. For example, a user named JohnSmith may select, as a user ID, JSMITH1 and an associated password foruse with a bank account. His brother, Joe Smith may select, as a userID, JSMITH2 and an associated password for use with a brokerage account.After a few months of non-use, Joe Smith attempts to log-in to hisbrokerage account. Not remembering his user ID, he thinks his user ID isJSMITH1. After unsuccessful log-in attempts, he contacts customerservice.

In the prior art, the typical method of customer service verifying theuser would be to verify ownership of the account. After verifyingseveral pieces of information with Joe Smith (e.g., social securitynumber, mailing address, etc.), the customer service representative isconvinced that Joe Smith is who he says he is and grants him access tohis brokerage account using the name JSMITH1. When John Smith latertries to log-in, the same scenario may occur, as John Smith is no longerto use the JSMITH1 name that he established and contacts customerservice to change the password. The result is that the JSMITH1 user IDbecomes associated with both the accounts of John Smith and Joe Smithand customer service needs to intervene in order to grant the userstheir desired authorization level.

There is thus no system that accurately associates customer relationshipand validates the ongoing integrity of the customer relationship. Inparticular, the prior art was solely concerned with verifying theownership of the account, and not verifying the relationship between theuser ID and the account. Such a problem may be exacerbated It isdesirable to have a more robust method of managing user identities in acomputerized system.

SUMMARY OF THE INVENTION

A system of the present invention for managing identities within anenterprise includes a registration component, an ownership component,and an audit component. The registration component is configured toassociate a user ID with specific accounts that are accessible via acomputer system. The ownership component is configured to verify theownership of the accounts. The audit component is configured to performperiodic checks to ensure the validity of the association between theuser ID and the ownership of the accounts.

A method of the present invention for issuing identities associated withaccounts may first receive a request for the creation of an identity.The request is processed by a component configured to determine theexisting methods used to authenticate users. Thereafter, using variousalgorithms, questions are generated that can be used to verify theidentity of the user. Answering the questions correctly is indicative ofthe fact that the user is who he says he is, therefore the identity canbe issued.

In addition, each transaction performed under the user identity isaggregated. Positive weighting can be assigned to successfultransactions that are indicative of a ownership of the underlyingaccount, while negative weighting can be assigned to unsuccessfultransactions. Thereafter, the weightings can be analyzed to verify thatthe user identity is being used by the true owner of the underlyingaccount.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived byreferring to the detailed description and claims when considered inconnection with the Figures, where like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 presents a block diagram overview of an embodiment of the presentinvention; and

FIG. 2 is a flow chart illustrating the process by which a user createsa user ID.

DETAILED DESCRIPTION

The present invention may be described herein in terms of variousfunctional components and various processing steps. It should beappreciated that such functional components may be realized by a varietyof different hardware or structural components configured to perform thespecified functions. For purposes of illustration only, exemplaryembodiments of the present invention will be described herein. Further,it should be noted that, while various components may be suitablycoupled or connected to other components, such connections and couplingsmay be realized by a direct connection between components, or by aconnection through other components and devices.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent exemplaryfunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical electronic transaction system.

The system may include a host server or other computing systemsincluding a processor for processing digital data, a memory coupled tosaid processor for storing digital data, an input digitizer coupled tothe processor for inputting digital data, an application program storedin said memory and accessible by said processor for directing processingof digital data by said processor, a display coupled to the processorand memory for displaying information derived from digital dataprocessed by said processor and a plurality of databases, said databasesincluding client data, merchant data, financial institution data and/orlike data that could be used in association with the present invention.As those skilled in the art will appreciate, user computer willtypically include an operating system (e.g., Windows NT, 95/98/2000,Linux, Solaris, etc.) as well as various conventional support softwareand drivers typically associated with computers. User computer can be ina home or business environment with access to a network. In an exemplaryembodiment, access is through the Internet through acommercially-available web-browser software package.

Database may be any type of database, such as relational, hierarchical,object-oriented, and/or the like. Common database products that may beused to implement the databases include DB2 by IBM (White Plains, N.Y.),any of the database products available from Oracle Corporation (RedwoodShores, Calif.), Microsoft Access or MSSQL by Microsoft Corporation(Redmond, Wash.), or any other database product. Database may beorganized in any suitable manner, including as data tables or lookuptables. Association of certain data may be accomplished through any dataassociation technique known and practiced in the art. For example, theassociation may be accomplished either manually or automatically.Automatic association techniques may include, for example, a databasesearch, a database merge, GREP, AGREP, SQL, and/or the like. Theassociation step may be accomplished by a database merge function, forexample, using a “key field” in each of the manufacturer and retailerdata tables. A “key field” partitions the database according to thehigh-level class of objects defined by the key field. For example, acertain class may be designated as a key field in both the first datatable and the second data table, and the two data tables may then bemerged on the basis of the class data in the key field. In thisembodiment, the data corresponding to the key field in each of themerged data tables is preferably the same. However, data tables havingsimilar, though not identical, data in the key fields may also be mergedby using AGREP, for example.

An embodiment of the present invention, with respect to FIG. 1, containsa registration component (102), an ownership component (104), and anaudit component (106). Registration component 102 is configured toregister new users and establish a relationship between the user ID andthe account or accounts related to the user ID. Ownership component 104is configured to define the criteria used to verify the ownership of theaccount. Audit component 106 is configured to validate the relationshipsbetween an account and a user ID on a regular basis. A user initiates aregistration process using component 110. If a customer needs help fromcustomer service (for example, the user lost his password), such aprocess can be initiated via component 112. An embodiment of the presentinvention may also be used in conjunction with pre-existing identitymanagement services (114), which has access to pre-existing serviceprofile data (118).

Communication between the parties to the transaction and the system ofthe present invention is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, transponder communicationsand/or the like. One skilled in the art will also appreciate that, forsecurity reasons, any databases, systems, or components of the presentinvention may consist of any combination of databases or components at asingle location or at multiple locations, wherein each database orsystem includes any of various suitable security features, such asfirewalls, access codes, encryption, de-encryption, compression,decompression, and/or the like.

The computer may provide a suitable website or other Internet-basedgraphical user interface which is accessible by users. In oneembodiment, the Internet Information Server, Microsoft TransactionServer, and Microsoft SQL Server, are used in conjunction with theMicrosoft operating system, Microsoft NT web server software, aMicrosoft SQL database system, and a Microsoft Commerce Server.Additionally, components such as Access or SQL Server, Oracle, Sybase,Informix MySQL, Intervase, etc., may be used to provide an ADO-compliantdatabase management system. The term “webpage” as it is used herein isnot meant to limit the type of documents and applications that might beused to interact with the user. For example, a typical website mightinclude, in addition to standard HTML documents, various forms, Javaapplets, Javascript, active server pages (ASP), common gateway interfacescripts (CGI), extensible markup language (XML), dynamic HTML, cascadingstyle sheets (CSS), helper applications, plug-ins, and the like.

In establishing a user ID, it is preferable that a set of criteria bepre-established to facilitate relating a user ID to an account. In thecontext of financial services, for example, a financial service providerhas a large set of data related to each account. In the instance where auser wishes to establish a user ID, registration component 102 hasaccess to subsets of that data, allowing an establishment of arelationship between a user ID and all accounts owned by the user. Forexample, a user wishes to access his bank account on-line. During theregistration process, registration component 102 can determine that, forexample, the user also owns a brokerage account and a credit accountfrom the same provider of the bank account. Thus, the user IDestablished by registration component 102 is associated with the bankaccount, the brokerage account, and the credit account.

Ownership component 104 is configured to establish rules to help ensurethat adequate ownership information is obtained from the user duringauthentication. For example, if a user wishes to associate a user ID toa brokerage account, ownership component 104 is configured to determinethe criteria needed to verify that the identity of the person requestingthe ID is the owner of the brokerage account. A user wishing toassociate a user ID to another type of account with less need forsecurity (e.g., the ability to check the balance of a credit account)may not utilize the same criteria. For example, access to a brokerageaccount may require that the user input a name, social security number,date of birth, and verify various bits of information. But access to abalance checking feature may only require the user to know the name andaccount number.

For a business organization with multiple business lines, ownershipcomponent 104 may be configured to evaluate each business line todetermine the authentication process each business line uses.Thereafter, ownership component 104 uses an algorithm to generate a setof questions or criteria that can be used by registration component 102to verify that the requesting user is the owner of the account.

With respect to FIG. 2, the process by which a user establishes a userID with a business comprising multiple business lines is illustrated. Auser accesses a business system and requests a user ID (step 202).Registration component 102 is activated and determines which accountsfrom the various businesses are to be associated with the user ID. In atypical usage, the user selects the various business lines he wishes tobe associated with the user ID. Thereafter, ownership component 104 isactivated (step 204). Ownership component 104 is configured to determinethe various schemes used by the selected business lines to authenticateusers (step 206). Then the various authentication processes are joinedin a rules-based algorithm to generate specific questions to be asked ofthe user attempting to obtain a user ID (step 208). After the usercorrectly answers the generated questions, registration component 102supplies the requested credentials to the user, indicating that the userwas validated. (Step 210). The credentials may be in the form of a userID/password combination, or other such access control means now known ordeveloped in the future.

Even though a set of relationships is robustly validated at the time ofthe creation of the relationships, the relationships can deteriorateover time, for a number of reasons. For example, account expiration,account re-issuance (e.g., due to a stolen credit card), change inmarital status (resulting in a no longer valid card that was issued to aspouse), change in address, and the like. In order to maintain anaccurate management of identities, it is preferable to periodicallymonitor the relationships.

An embodiment of audit component 106 of the present invention utilizes amathematical weighting function that assigns values to specificinteractions captured by the system. Interactions that serve to confirmthe identity of the user are assigned positive values. Examples of thesetypes of interaction include the payment of balances, the receipt ofmerchandise, and similar transactions where it is unlikely that anunauthorized user performed the transaction. Interactions that serve toundermine the identity of the user are assigned negative values.Examples of such interactions include non-payment of bills, requests toreceive merchandise at alternate locations.

Additionally, certain interactions may be weighted in aggregate form. Inother words, some combinations of events may have relationships witheach other. For example, a series of identity-undermining events mayhave an aggregate negative weighting that exceeds the individualnegative weightings described above.

Aggregated behaviors may also include usage behaviors that can becaptured as patterns using, for example, conventional pattern matchingalgorithms. Each usage can be compared to a typical usage pattern.Typical usage may include the typical tasks performed by the user, thelocation of the user (which can be determined, for example, via the IPaddress or addresses from which they typically connect). This patterndata may be updated at regular intervals. For example, each time theuser accesses the system, a similarity score can be computed thatindicates the similarity of the transaction to previous transactions.Therefore, each usage of the system establishes a usage history for theuser. Thus, previous usage can be logged and compared to each subsequentusage.

Other information that can be stored includes more detailed informationregarding the console the user is using. For example, the type ofbrowser, the type of computer, the operating system, and the like, maybe accessible when a user accesses the computer system.

Another embodiment of the present invention records various informationabout a user each time the user accesses the computer system. Examplesof the information collected include the IP address from which the useraccesses the computer system; the browser being used; the transactionsperformed on the computer system; the time of the access; and the like.This information may be collected each time the user accesses thecomputer system. At each subsequent access to the computer system, suchinformation can be compared to connection information previouslycollected. If the information is very similar, the user can continue toperform transactions. However, if the information is different, moreinformation may be requested from the user to confirm the user'sidentity.

The certainty measure may also be increased through the usage ofspecific questions that only a particular person would know the answerto, prior to allowing the user to perform certain transactions. Forexample, additional questions may be asked when a user attempts totransfer funds, obtain a cash advance, or other such transactions thathave been determined to require more security to perform. Such questionsare more specific and would only be known to the card holder, and not tothose who, for example, steal a credit card. Such a question may includequeries regarding previous purchases, questions regarding associatedaccounts, and the like, in addition to questions regarding the accountholder, such as address, social security number, date of birth, and thelike. The questions asked can be determined algorithmically usingvarious methods. Correct answers to such questions not only allow theuser to perform the requested tasks, but also increase theabove-described certainty measure of the user.

It can thus be seen that the above-described problems can be eliminatedby an embodiment of the present invention. For example, it would not bepossible for the owner of user ID JSMITH2 to obtain access to the userID JSMITH1, as the ownership component would determine that, although heis the owner of an account, he is not the owner of the accountassociated with the JSMITH1 user ID.

The present invention is described herein with reference to blockdiagrams, flowchart illustrations of methods, systems, and computerprogram products according to various aspects of the invention. It willbe understood that each functional block of the block diagrams and theflowchart illustrations, and combinations of functional blocks in blockdiagrams and flowchart illustrations, respectively, may be implementedby computer program instructions. These computer program instructionsmay be loaded on a general purpose computer, special purpose computer,or other programmable data processing apparatus to produce a machine,such that the instructions which execute on the computer or otherprogrammable data processing apparatus create means for implementing thefunctions specified in the flowchart block or blocks.

It will be appreciated, that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. It is noted that the networkmay be implemented as other types of networks, such as an interactivetelevision (ITV) network. The users may interact with the system via anyinput device such as a keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot®), cellular phone and/orthe like. Similarly, the invention could be used in conjunction with anytype of personal computer, network computer, workstation, minicomputer,mainframe, or the like running any operating system such as any versionof Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOS,OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, although theinvention is frequently described herein as being implemented withTCP/IP communications protocols, it will be readily understood that theinvention could also be implemented using IPX, Appletalk, IP-6, NetBIOS,OSI or any number of existing or future protocols. Moreover, the systemcontemplates the use, sale or distribution of any goods, services orinformation over any network having similar functionality describedherein.

The computing units may be connected with each other via a datacommunication network. The network may be a public network and assumedto be insecure and open to eavesdroppers. In the illustratedimplementation, the network may be embodied as the interne. In thiscontext, the computers may or may not be connected to the internet atall times. For instance, the customer computer may employ a modem tooccasionally connect to the internet, whereas the bank computing centermight maintain a permanent connection to the internet. Specificinformation related to the protocols, standards, and applicationsoftware utilized in connection with the Internet may not be discussedherein. For further information regarding such details, see, forexample, DILIP NAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2COMPLETE, various authors, (Sybex 1999); DEBORAH RAY AND ERIC RAY,MASTERING HTML 4.0 (1997). LOSHIN, TCP/IP CLEARLY EXPLAINED (1997). Allof these texts are hereby incorporated by reference.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded on a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, it will be appreciated thatvarious modifications and changes can be made without departing from thescope of the present invention. The specification and figures are to beregarded in an illustrative manner, rather than a restrictive one, andall such modifications are intended to be included within the scope ofpresent invention.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. No elementdescribed herein is required for the practice of the invention unlessexpressly described as “essential” or “critical”.

1. An audit system comprising: a processor for auditing; a memory; anetwork interface communicating with said memory; said memorycommunicating with said processor; and said processor, when executing acomputer program, performs operations comprising: aggregating, by saidprocessor, positive weights and negative weights to determine a usagehistory of said user, wherein said positive weights relate to successfultransactions and said negative weights relate to unsuccessfultransactions; removing, by said processor, a relationship between anidentity and an account in response to said aggregation failing to meeta predetermined criteria; issuing, by said processor, said identity tosaid user in response to at least a portion of said authenticationquestions being correctly answered, wherein said authenticationquestions to be asked are based upon said authentication rulesassociated with said account; and monitoring, by said processor, changesin a relationship between said user and said identity of an account overa period of time to periodically perform an automatic adjustment of saidauthentication questions in response to a deterioration of saidrelationship, wherein said deterioration of said relationship is basedupon activity of said user.
 2. The audit system of claim 1, furthercomprising confirming ownership of said account.
 3. The audit system ofclaim 1, further comprising confirming ownership of said account byanalyzing ownership data and generating said authentication questions tobe asked of said user to verify said identity actually belongs to saiduser.
 4. The audit system of claim 1, further comprising determiningsaid authentication rules associated with said account.
 5. The auditsystem of claim 1, wherein said successful transaction is based onsecurity requirements of said account and risk factors relating tovarious transaction types associated with said account.
 6. The auditsystem of claim 1, wherein said positive weight is for a similartransaction by said user, wherein said similar transaction is based oncomparing said current transaction to previous transactions performed bysaid user.
 7. The audit system of claim 1, further comprising issuingsaid identity to said user in response to at least a portion of saidauthentication questions being correctly answered, wherein saidauthentication questions to be asked are based upon said authenticationrules associated with said account.
 8. The audit system of claim 1,further comprising monitoring, by said processor, aggregated behaviors,wherein said aggregated behaviors are used to weight transactions tofurther verify ownership of said account.
 9. The audit system of claim1, further comprising determining authentication rules associated withsaid account, wherein authentication questions to be asked of a user arebased upon said authentication rules.
 10. The audit system of claim 1,further comprising receiving a request for an identity associated withsaid account.
 11. A method comprising: aggregating, by a computer-basedsystem for auditing, positive weights and negative weights to determinea usage history of said user, wherein said positive weights relate tosuccessful transactions and said negative weights relate to unsuccessfultransactions; removing, by said computer-based system, a relationshipbetween an identity and an account in response to said aggregationfailing to meet a predetermined criteria; issuing, by saidcomputer-based system, said identity to said user in response to atleast a portion of said authentication questions being correctlyanswered, wherein said authentication questions to be asked are basedupon said authentication rules associated with said account; andmonitoring, by said computer-based system, changes in a relationshipbetween said user and said identity of an account over a period of timeto periodically perform an automatic adjustment of said authenticationquestions in response to a deterioration of said relationship, whereinsaid deterioration of said relationship is based upon activity of saiduser.
 12. The method of claim 11, further comprising confirmingownership of said account.
 13. The method of claim 11, furthercomprising confirming ownership of said account by analyzing ownershipdata and generating said authentication questions to be asked of saiduser to verify said identity actually belongs to said user.
 14. Themethod of claim 11, wherein said successful transaction is based onsecurity requirements of said account and risk factors relating tovarious transaction types associated with said account.
 15. The methodof claim 11, wherein said positive weight is for a similar transactionby said user, wherein said similar transaction is based on comparingsaid current transaction to previous transactions performed by saiduser.
 16. The method of claim 11, further comprising issuing saididentity to said user in response to at least a portion of saidauthentication questions being correctly answered, wherein saidauthentication questions to be asked are based upon said authenticationrules associated with said account.
 17. The method of claim 11, furthercomprising monitoring, by said processor, aggregated behaviors, whereinsaid aggregated behaviors are used to weight transactions to furtherverify ownership of said account.
 18. The method of claim 11, furthercomprising determining authentication rules associated with saidaccount, wherein authentication questions to be asked of a user arebased upon said authentication rules.
 19. The method of claim 11,further comprising receiving a request for an identity associated withsaid account.
 20. An article of manufacture including a non-transitory,tangible computer readable medium having instructions stored thereonthat, in response to execution by a computer-based system for auditing,cause said computer-based system to perform operations comprising:aggregating, by said computer-based system, positive weights andnegative weights to determine a usage history of said user, wherein saidpositive weights relate to successful transactions and said negativeweights relate to unsuccessful transactions; removing, by saidcomputer-based system, a relationship between an identity and an accountin response to said aggregation failing to meet a predeterminedcriteria; issuing, by said computer-based system, said identity to saiduser in response to at least a portion of said authentication questionsbeing correctly answered, wherein said authentication questions to beasked are based upon said authentication rules associated with saidaccount; and monitoring, by said computer-based system, changes in arelationship between said user and said identity of an account over aperiod of time to periodically perform an automatic adjustment of saidauthentication questions in response to a deterioration of saidrelationship, wherein said deterioration of said relationship is basedupon activity of said user.